home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000146_owner-urn-ietf _Thu Oct 31 15:14:20 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA19270 for urn-ietf-out; Thu, 31 Oct 1996 15:14:20 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA19262 for <urn-ietf@services.bunyip.com>; Thu, 31 Oct 1996 15:14:17 -0500
  3. Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA27979  (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 15:14:16 -0500
  5. Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id NAA06916; Thu, 31 Oct 1996 13:14:13 -0700 (MST)
  6. Message-Id: <2.2.32.19961031202200.0070afc8@acl.lanl.gov>
  7. X-Sender: rdaniel@acl.lanl.gov
  8. X-Mailer: Windows Eudora Pro Version 2.2 (32)
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset="us-ascii"
  11. Date: Thu, 31 Oct 1996 13:22:00 -0700
  12. To: Terry Allen <tallen@fsc.fujitsu.com>, urn-ietf@bunyip.com
  13. From: Ron Daniel <rdaniel@acl.lanl.gov>
  14. Subject: [URN] Re: ig
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: Ron Daniel <rdaniel@acl.lanl.gov>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20. Thus spoke Terry Allen (at least at 11:52 AM 10/31/96 -0800)
  21.  
  22. >That's good, but I can't find any way to use Accept: to limit
  23. >the absolute number of resources that the client is willing
  24. >to receive.  Have I missed it?
  25.  
  26. No, Accept: was intended to be used for returning one and only one
  27. version of a resource. N2Rs is rather strange for HTTP, so none of
  28. its headers are going to be intended for such a context. (But they
  29. accomodate it easily, 200 OK is still 200 OK).
  30.  
  31. >An image library might have scads of GIFs of the same object:
  32. >the Parthenon in 1932, the P in 1964, the P at sunrise, the P
  33. >under moonlight ... but it will be difficult to know in advance
  34. >how to twiddle the Accept: information so as not to be inundated
  35. >by Parthenons in response.
  36.  
  37. They may have lots of images of the same object, but I doubt that
  38. those images will have identical URNs.
  39.  
  40. More likely is where we have something like a Kodak PhotoCD with
  41. the same image at different resolutions. N2Rs would return a
  42. multipart with all those different resolutions.
  43.  
  44.  
  45. >  Or maybe that's okay and users should
  46. >be warned that they may get more than the bargained for when they
  47. >use N2Rs?
  48.  
  49. That's my attitude, but then I tend toward the "let them shoot their
  50. foot off" approach.
  51.  
  52. Ron Daniel Jr.                       email: rdaniel@lanl.gov
  53. Advanced Computing Lab               voice: +1 505 665 0597
  54. MS B287                                fax: +1 505 665 4939
  55. Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
  56. Los Alamos, NM, USA  87545    obscure_term: "hyponym"
  57.